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B-197731 


To  the  President  of  the  Senate  and  the 
Speaker  of  the  House  of  Representatives 

This  report  points  out  problems  in  Department  of 
Defense  management  of  the  Battlefield  Exploitation  and 
Target  Acquisition  project.  We  made  the  review  to  deter¬ 
mine  if  technology  development  objectives  were  being 
achieved.  We  are  recommending  that  the  Secretary  of 
Defense  modify  planned  development  efforts  to  make  the 
project  cost  effective. 


We  are  sending  copies  of  this  report  to  the  Chairmen, 
House  and  Senate  Committees  on  Intelligence  and  on  Defense 
Appropriations;  the  Secretary  of  Defense;  the  Secretaries 
of  the  Army,  Air  Force,  and  Navy;  and  the  Director,  Office 
of  Management  and  Budget. 


mptrolle’-  General 
of  the  United  States 
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COMPTROLLER  GENERAL'S 
REPORT  TO  THE  CONGRESS 


EVALUATION  OF  DEFENSE 
ATTEMPTS  TO  MANAGE 
BATTLEFIELD  INTELLIGENCE  DATA 


DIGEST 

The  Battlefield  Exploitation  and  Target 
Acquisition  (BETA)  project  was  initiated 
in  September  1977  as  a  joint  service  ex¬ 
periment  to  develop  a  test  bed  for  auto¬ 
mated  collection,  analysis,  correlation, 
and  dissemination  of  tactical  intelligence 
data.  The  BETA  test  bed  includes  ground 
stations  which  receive  sensor  messages,  cor¬ 
relation  centers  that  automatically  process 
the  sensor  data,  operator  terminals  for  dis¬ 
playing  correlation  center  output,  and  commu¬ 
nications  equipment  to  route  sensor  messages 
and  distribute  reports. 

The  experiment  was  estimated  to  cost  $98  mil¬ 
lion  through  completion  in  fiscal  year  1984. 
However,  in  June  1980  congressional  commit¬ 
tees  redirected  the  project  after  learning 
of  BETA'S  development  schedule  slippage, 
inordinate  cost  increases,  reduced  capabili¬ 
ties,  and  poor  performance  during  testing. 

The  committees  asked  that  current  project 
funding  be  used  to  complete  software  develop¬ 
ment  and  to  correct  test  bed  deficiencies. 
Instead  of  continuing  with  a  technology 
demonstration  project,  the  Secretary  of  De¬ 
fense  was  to  provide  the  Congress  with  an 
acquisition  plan  by  September  30,  1980,  for 
joint  service  development  and  acquisition 
of  a  fielded  system.  This  system  was  to  build 
on  BETA  software  already  developed  and  make 
maximum  use  of  common  hardware. 

GAO  reviewed  the  status  of  the  BETA  project 
and  concluded  that: 

— Its  capabilities  were  not  sufficiently 
developed  and  tested  to  provide  a  base¬ 
line  for  the  early  fielding  of  an  opera¬ 
tional  system,  and  considerable  corrective 
action  is  needed  to  achieve  this  goal. 

For  example,  it  does  not  process  the  re¬ 
quired  volume  of  sensor  data  or  process 
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the  data  within  required  response  times. 

The  current  test  phase  needs  to  be  com¬ 
pleted  to  provide  sufficient  technical 
information  for  the  engineering  devel¬ 
opment  effort  directed  by  the  Congress. 

(See  pp.  13  and  24.  ) 

— Pressure  from  Department  of  Defense  man¬ 
agement  to  test  BETA  in  a  September  1980 
European  demonstration  contributed  signif¬ 
icantly  to  project  development  problems 
such  as  cost  growth  and  reduced  perform¬ 
ance  requirements.  (See  p.  24.) 

— Prior  to  congressional  direction  to  form  a 
joint  service  project,  the  Air  Force  was 
the  only  service  committed  to  using  the 
BETA  design  and  software  to  facilitate  the 
early  fielding  of  an  operational  correla¬ 
tion  system.  (See  p.  5.  ) 

— The  Army,  which  requires  functions  in  addi¬ 
tion  to  those  provided  by  BETA,  planned 
further  test  bed  experiments  while  it  con¬ 
tinued  analyzing  its  correlation  system 
requirements.  The  Navy  and  Marine  Corps 
foresee  very  limited  application  of  present 
BETA  technology  to  their  projects.  (See 
pp.  7,  9,  and  11.) 

RECOMMENDATIONS 

In  view  of  development  problems  experienced 
by  the  BETA  project,  GAO  recommends  that 
the  Secretary  of  Defense  include  the  follow¬ 
ing  provisions  in  the  revised  project  plan 
requested  by  the  Congress: 

— The  principal  objective  of  future  BETA 
efforts  should  be  to  support  the  early 
fielding  of  a  joint  service  tactical  eche¬ 
lon  correlation  system  to  meet  Army  and 
Air  Force  operational  requirements  for  the 
1980s. 

— An  overall  schedule  for  system  engineering 
development  and  early  fielding,  as  well  as 
corresponding  funding  requirements. 
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— An  orderly,  well-planned,  software  devel¬ 
opment  process  that  progresses  based  on 
achievement  of  performance  goals  instead  of 
a  time  schedule.  This  process  should  start 
with  a  6  to  8  month  "f ind-and-f ix"  phase  to 
correct  major  software  discrepancies  in  the 
test  bed. 

— A  firm  Army  commitment  to  utilize  the  BETA 
system  architecture  to  fulfill  a  portion 
of  its  tactical  fusion  requirements,  so 
that  a  joint  project  can  make  maximum  use 
of  existing  software  and  common  hardware. 

— Navy  definition  of  a  technical  approach  for 
integrating  BETA'S  ground  target  nominations 
into  shipboard  command  and  control  systems. 

— Marine  Corps  analyses  comparing  its  correla¬ 
tion  system  requirements  with  planned  BETA 
capabilities,  and  subsequently,  a  plan  that 
defines  how  BETA  can  be  used  to  satisfy 
these  requirements. 

— An  acquisition  strategy  that  will  maximize 
use  of  BETA  software  to  the  extent  techni¬ 
cally  feasible.  (See  p.  25.) 

AGENCY  COMMENTS 

The  Department  of  Defense  suggested  that  GAO 

clarify  statements  concerning  the  services' 

intended  use  of  BETA  technology: 

— The  Army  intends  to  use  BETA  technology 
where  appropriate.  However,  it  declined 
to  make  a  commitment  at  this  time  to  use 
the  BETA  system  architecture,  and  it  wishes 
to  consider  the  applicability  of  another 
system  under  development. 

— The  Navy  agrees  with  the  need  to  define  a 
technical  approach  for  providing  informa¬ 
tion  on  ground  targets  to  its  forces,  but 
believes  that  it  is  premature  to  assume 
that  BETA'S  ground  target  nominations 
should  be  integrated  into  shipboard  com¬ 
mand  and  control  systems. 
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— The  Marine  Corps  advised  that  it  will 
evaluate  the  applicability  of  BETA  tech¬ 
nology  to  a  system  currently  under  de¬ 
velopment.  (See  p.  26.) 

CONTRACTOR  COMMENTS 

TRW,  Inc.,  considers  this  report  to  be  objec 
tive  and  constructive  and  advises  that  the 
"f ind-and-f ix"  phase  is  being  conducted  and 
progress  has  been  made  in  correcting  the 
technical  problems  which  existed  during  GAO* 
review.  (See  p.  19. ) 
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CHAPTER  1 


INTRODUCTION 


Military  commanders  have  a  need  to 

— support  near  real-time  targeting; 

— identify  enemy  axes  of  advance  and  capabilities  with 
sufficient  detail  and  at  sufficient  range  to  allow 
the  timely  and  effective  deployment  of  friendly 
forces,  at  all  tactical  levels,  and  to  support  opera¬ 
tions  to  intercept  enemy  forces;  and 

— rapidly  determine  high  value  targets,  such  as  enemy 
command  and  control  systems,  to  allow  immediate  ex¬ 
ploitation  by  commands  at  all  levels. 

To  help  meet  these  requirements,  the  Battlefield 
Exploitation  and  Target  Acquisition  (BETA)  test  bed  1/  proj¬ 
ect  was  conceived  to  demonstrate  the  feasibility  and  utility 
of  prompt  coupling  of  target  acquisition  sensors  into  tacti¬ 
cal  combat  situation  displays  and  firepower  systems. 

The  BETA  test  bed  is  essentially  composed  of  ground 
stations  which  receive  sensor  messages,  correlation  centers 
(sometimes  referred  to  as  fusion  centers)  that  automatically 
process  the  sensor  data,  operator  terminals  for  displaying 
and  correlating  the  information,  and  communications  equipment 
to  route  messages  and  distribute  reports.  The  BETA  project 
requires  a  complex  arrangement  of  personnel  and  equipment, 
including  computers  and  software,  to  handle  the  large  volume 
of  sensor  data  within  established  time  frames. 

Sensor  messages  provide  intelligence  data  on  potential 
ground  threats,  such  as  artillery  sites,  command  posts,  as¬ 
sembly  areas,  air  defense  sites,  and  tank  formations.  These 
messages  include  data  on  location  of  threat,  time  of  detec¬ 
tion,  and  identification  of  target  type.  After  this  data  is 
passed  to  a  BETA  correlation  center,  it  is  automatically  or¬ 
ganized  and  correlated  with  intelligence  data  already  on 
file  to  create  an  updated  record  on  the  threat  entity. 


1/A  test  bed  is  an  experimental  model  of  a  military  system 
which  is  used  to  develop  and  test  new  technology. 
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Alphanumeric  or  graphic  data  can  then  be  displayed  at 
operator  terminals  for  intelligence  analysts'  use.  (See 
app.  Ill  for  schematic  of  BETA  architecture  and  app.  IV 
for  pictures  of  test  bed  subsystems.) 

Specif ically,  the  BETA  project  was  conceived  on  the 
premise  that  timely  correlation  and  dissemination  of  near 
real-time  sensor  data  can  be  used  to  enhance  the  selective 
application  of  firepower  against  a  numerically  superior 
force.  The  Office  of  the  Secretary  of  Defense  (OSD)  believes 
that  the  projected  enemy  threat  in  a  major  conventional  con¬ 
flict  requires  a  highly  responsive  command,  control,  communi¬ 
cations,  and  intelligence  system  to  allocate  and  maneuver 
forces  effectively  and  to  select  and  strike  critical  targets 
successfully.  Also,  successful  combat  requires  air  and 
ground  forces  to  have  a  common  perception  of  the  battlefield 
and  a  highly  responsive  interaction.  This  requirement  in¬ 
cludes  automating  the  correlation  and  dissemination  of  sensor 
reports  to  ensure  timely  battlefield  use  of  intelligence  data. 
When  advanced  sensor  systems  are  fielded,  they  will  accurately 
detect  and  identify  enemy  land  targets  at  long  ranges  and 
may  provide  the  continuous  capability  to  see  the  battlefield 
and  produce  large  volumes  of  precise  data.  Automation  is 
required  because  this  vast  volume  of  data  could  not  be  assim¬ 
ilated,  correlated,  and  displayed  using  manual  methods. 

DEVELOPMENT  HISTORY  AND  PLANS 


The  need  for  an  experimental  system  was  identified  after 
several  years  of  study  by  the  Defense  Advanced  Research  Proj¬ 
ects  Agency.  Based  on  the  Agency's  proposal,  in  May  1977  the 
Undersecretary  of  Defense,  Research  and  Engineering  directed 
the  services  to  support  the  Agency  in  developing  BETA.  This 
system  was  to  be  tested  during  a  European  exercise  scheduled 
for  September  1980. 

The  Army  and  Air  Force  elected  to  carry  out  this  direc¬ 
tion  and,  with  OSD  approval,  established  a  joint  project 
office  in  September  1977.  The  Array  was  assigned  to  manage 
the  project.  In  November  1977  a  Request  For  Proposal  was 
issued  to  obtain  a  system  contractor.  A  letter  contract  was 
signed  in  March  1978  with  TRW,  Inc.  The  contractor's  effort 
included  developing  software  and  integrating  it  with  hardware 
obtained  from  subcontractors.  The  definitized  contract  was 
signed  in  August  1978  after  congressional  approval  of  addi¬ 
tional  project  funding.  This  funding  approval  was  conditional 
upon  (1)  active  participation  in  the  BETA  project  by  the  Navy, 
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the  Marine  Corps,  and  the  national  intelligence  community  so 
that  BETA  would  be  a  Department  of  Defense-wide  program  and 
(2)  development  of  a  processing  system  which  would  handle 
sensor  data  from  all  services,  including  national  intelli¬ 
gence  systems. 

In  January  1980  OSD  approved  a  plan  for  continuing  the 
BETA  technology  development  after  the  European  demonstration. 
The  objectives  of  this  plan  were  to  (1)  complete  development 
of  software  functions  previously  eliminated,  (2)  make  soft¬ 
ware  improvements  which  are  necessary  to  support  wartime  data 
loads  on  the  system,  (3)  develop  a  battlefield  simulator  to 
permit  evaluation  of  BETA  and  follow-on  service  systems  at 
expected  combat  data  loads,  and  (4)  participate  in  field  ex¬ 
ercises  to  support  evaluation  of  evolving  sensor  and  communi¬ 
cations  technologies  while  demonstrating  interoperability 
with  other  command  and  control  systems.  The  BETA  project  was 
estimated  to  cost  $98  million  through  completion  in  fiscal 
year  1984. 

OBJECTIVES,  SCOPE,  AND  METHODOLOGY 

We  evaluated  the  BETA  project  to  determine  if  project 
objectives  were  being  achieved  and  if  it  was  cost  effective 
to  continue  as  planned  with  the  test  bed  development. 
Accordingly,  we  reviewed  (1)  planned  test  bed  capabilities 
to  ascertain  the  extent  of  automation  being  provided,  (2) 
results  of  tests  and  evaluations  to  determine  if  the  current 
test  bed  configuration  met  contract  specifications  and  was 
operationally  effective,  and  (3)  service  plans  for  utilizing 
BETA  technology  to  ascertain  if  the  expected  benefits  jus¬ 
tify  project  cost.  We  periodically  discussed  our  findings 
in  detail  with  staffmembers  from  the  House  Permanent  Select 
Committee  on  Intelligence  and  the  Subcommittee  on  Defense, 
[louse  Committee  on  Appropriations. 

We  examined  project  plans,  correspondence,  contract 
specifications,  test  plans  and  reports,  and  cost  estimates 
and  observed  BETA  tests  which  were  performed  during  the 
review.  In  addition,  we  interviewed  project  management  offi¬ 
cials  responsible  for  BETA  development  and  service  officials 
who  developed  requirements  for,  or  managed,  related  projects 
which  were  considering  the  application  of  BETA  technology. 

Our  review  was  principally  conducted  at  the  BETA  Project 
Office,  Harry  Diamond  Laboratories,  Adelphi,  Maryland.  In 
addition,  we  visited  the  following  contractor  and  service 
organizations: 

--TRW,  Inc.,  Redondo  Beach,  California. 


-Department  of  the  Army  Headquarters,  Washington,  D.C. 

-All  Source  Analysis  System  Project  Office,  U.S. 

Army  Electronics  Research  and  Development  Command, 
Vint  Hill  Farms,  Virginia. 

-U.S.  Army  Training  and  Doctrine  Command  organizations 
at  Fort  Monroe,  Virginia;  Fort  Huachucha,  Arizona; 
and  Fort  Leavenworth,  Kansas. 

-Chief  of  Naval  Operations,  Washington,  D.C. 

-Air  Force  Systems  Command,  Washington,  D.C. 

-Air  Force  Tactical  Air  Command,  Langley  Air  Force 
Base,  Virginia. 

-Tactical  Fusion  Division  Project  Office,  Electronics 
System  Division,  Hanscom  Field,  Massachusetts. 

-Marine  Corps  Director  of  Intelligence,  Washington, 
D.C. 
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CHAPTER  2 


SERVICES  PLAN  LIMITED  UTILIZATION 
OF  BETA  TECHNOLOGY 


One  of  the  principal  objectives  of  the  BETA  project 
was  to  develop  computer-based  intelligence  data  processing 
technology  that  would  facilitate  interoperability  and  equip¬ 
ment  standardization  among  the  services  for  correlation 
center  operations.  However,  significant  research  and  devel¬ 
opment  funds  were  invested  in  the  BETA  project  without 
adequate  service  commitment  to  directly  apply  the  technology 
to  ongoing  or  planned  correlation  center  developments.  The 
Air  Force  was  the  only  service  committed  to  using  the  BETA 
test  bed  design  and  software  to  facilitate  early  fielding  of 
an  operational  system.  The  Army  was  uncertain  about  its  sys¬ 
tem  requirements  and  was  only  committed  to  further  BETA  test 
bed  experimentation.  The  Navy  and  Marine  Corps  are  monitor¬ 
ing  BETA  project  results  and  are  considering  participation  in 
joint  exercises,  but  these  services  foresee  very  limited 
application  to  their  own  projects  at  this  time. 

The  BETA  test  bed  is  specifically  designed  to  satisfy 
service  requirements  for  fusing  intelligence  data  involving 
ground  targets.  Recognizing  that  future  BETA  tests  may  dis¬ 
close  some  service  unique  requirements,  a  joint  service 
development  effort,  using  the  same  intelligence  data  process¬ 
ing  technology,  fosters  considerable  interoperability  in 
battle  management  as  well  as  significant  cost  savings.  The 
benefits  to  be  realized  by  this  approach  should  substantially 
outweigh  the  disadvantages. 

BENEFITS  ACHIEVABLE  THROUGH 
TRANSFER  OF  BETA  TECHNOLOGY 


Specific  benefits  that  could  be  realized  by  the  BETA 
project  include  the  following: 

— Development  of  automated  data  correlation  and  situa¬ 
tion  display  techniques  for  responsive  dissemination 
and  processing  of  sensor  information. 

— Identification  of  communication  requirements  to  sup¬ 
port  multiservice  sensor  utilization. 

— Assistance  to  the  North  Atlantic  Treaty  Organization 
in  defining  requirements  for  automated  facilities  at 
the  tactical  level. 


5 


— Provision  of  a  suitable  test  bed  for  the  services  to 
validate  functional  requirements  and  develop  software 
and  procedures  for  effective  command  and  control  of 
joint  tactical  forces,  particularly  during  a  time  of 
crisis. 

— Development  of  software  for  direct  transfer  to  corre¬ 
lation  center  projects,  facilitating  the  early  field¬ 
ing  of  operational  systems. 

Some  of  these  benefits  have  already  been  realized.  For 
example,  communications  protocols,  message  standards  and  for¬ 
mats,  and  operational  procedures  for  joint  service  utiliza¬ 
tion  of  sensor  data  have  already  been  developed.  Also,  the 
BETA  project  has  developed  working  interfaces  with  12  separate 
sensor  systems  that  formerly  operated  with  their  own  message 
standards  and  computer  architectures.  Project  officials  have 
advised  that  if  the  technology  lessons  learned  from  BETA  are 
adopted  by  our  military,  this  would  greatly  facilitate  inter¬ 
operability  and  equipment  standardization.  This  would  provide 
a  substantially  improved  capability  for  giving  operational  di¬ 
rection  to  our  military,  particularly  during  a  time  of  crisis. 
Irrespective  of  these  benefits,  the  services'  planned  use  of 
BETA  technology  will  be  limited 

AIR  FORCE  PLANNED  USE 
OF  BETA  TECHNOLOGY 

The  Air  Force  has  a  requirement  for  a  mobile,  real-time 
system  that  can  process  and  correlate  large  volumes  of  intel¬ 
ligence  data.  This  volume  of  data  is  expected  to  increase 
substantially  in  the  1980s.  To  meet  this  requirement,  the 
Air  Force  planned  the  development  of  the  Tactical  Fusion 
Division  System.  Although  a  system  feasibility  study  was 
completed  in  1977,  the  Air  Force  deferred  system  development 
efforts  because  of  the  BETA  project.  Subsequently,  the  Air 
Force  planned  to  start  the  engineering  development  of  the 
Tactical  Fusion  Division  System  during  fiscal  year  1981, 
using  BETA  software  and  compatible  computer  equipment  which 
meets  military  specifications.  The  Air  Force  planned  to 
field  an  operational  system  in  1984. 

The  Air  Force's  plan  is  not  without  some  technological 
risks.  For  example,  although  adequate  for  test  bed  purposes, 
commercial  off-the-shelf  computers  and  related  equipment 
used  for  the  BETA  project  are  too  large,  heavy,  and  fragile 
to  meet  the  Air  Force's  mobility  requirements.  Versions  of 
computers  used  in  the  BETA  correlation  center  which  meet 
military  specifications  are  available  from  vendors,  but  a 


major  effort  will  be  needed  to  develop  suitable  operator 
terminals  which  can  both  meet  mobility  requirements  and 
use  BETA-developed  software  with  minimal  change.  This  will 
require  specification  of  a  terminal  design  that  is  compati¬ 
ble  with  the  instruction  set  architecture  of  the  terminals 
used  in  the  BETA  test  bed.  Air  Force  officials  see  this 
operator  terminal  development  as  a  major  risk. 

Another  major  risk  associated  with  the  BETA  project  is 
software  development.  The  Air  Force  has  a  mission  require¬ 
ment  to  process  up  to  4,000  sensor  messages  an  hour.  Although 
this  requirement  was  included  in  BETA'S  contract  specifica¬ 
tions,  to  date  the  BETA  test  bed  has  not  been  tested  at  that 
message  load.  During  initial  system  integration  testing, 

BETA  could  not  operate  under  a  message  load  exceeding  1,300 
messages  an  hour.  In  addition,  the  Air  Force  believes  that 
future  testing  may  identify  some  unique  service  requirements. 

ARMY  IS  UNCERTAIN  ABOUT  REQUIREMENTS 

The  Army  plans  to  field  a  partial  All  Source  Analysis 
System  (ASAS)  capability  by  1985  while  it  developes  the  full 
system  capability  it  believes  is  required  for  the  future. 

In  addition  to  correlation  and  dissemination  of  sensor  data, 
ASAS  capability  will  include  other  intelligence  management 
functions  to  support  corps  and  division  echelon  commanders. 

The  initial  system,  designated  "Early  Fielding  ASAS,"  was  to 
include  automated  input  processing  and  data  base  retrieval 
and  display,  but  automated  analysis  would  have  been  limited. 
The  Army  intended  to  incorporate  capabilities  of  existing 
programs,  such  as  BETA,  to  the  extent  feasible.  The  Army 
is  currently  studying  overall  ASAS  design  and  functional 
requirements.  However,  at  the  time  of  our  review,  the  Army 
was  uncertain  to  what  extent  BETA-like  capabilities  would  be 
incorporated.  Also,  the  Army  wanted  to  analyze  the  results 
of  BETA  testing  before  it  committed  itself  to  direct  software 
transfer  to  support  an  early  fielding  of  ASAS.  At  the  pres¬ 
ent  time,  the  Army  is  committed  to  test  bed  experiments  to 
validate  ASAS  requirements. 

In  July  1978  the  U.S.  Army  Training  and  Doctrine  Command 
proposed  ASAS  development.  Army  Headquarters  approved  this 
proposal  in  February  1979,  with  the  condition  that  an  indepth 
operational  concept  and  functional  description  study  be 
prepared.  Further,  initial  efforts  were  limited  to  signal 
intelligence/electronic  warfare  functions,  and  BETA  project 
results  were  to  be  assessed  for  applicability  to  the  ASAS 
requirement. 


A  plan  was  formulated  to  concurrently  test  BETA  with 
an  automated  files  management  system,  called  the  Technical 
Control  and  Analysis  Center,  and  an  advanced  development 
model  of  an  ASAS  subsystem  for  compartmented  processing  of 
special  intelligence  data.  Test  results  were  to  be  used 
for  defining  requirements  for  automated  intelligence  infor¬ 
mation  processing  at  both  corps  and  division  echelons  so 
that  an  ASAS  engineering  development  program  could  start 
in  fiscal  year  1981.  This  evaluation  was  to  be  performed 
during  fiscal  year  1980  in  both  the  United  States  and 
Europe.  According  to  Army  officials,  this  plan  could  not 
be  implemented  because  Technical  Control  and  Analysis  Center 
development  fell  18  months  behind  schedule  due  to  a  delay  in 
reprograming  funds. 

Under  the  Army's  revised  acquisition  strategy,  various 
system  options  were  being  considered  to  fulfull  the  require¬ 
ment  for  early  fielding  of  ASAS.  These  options  included  a 
version  of  BETA  which  meets  military  specifications,  the 
Tactical  Control  and  Analysis  Center,  an  Interim  Tactical 
Electronic  Intelligence  Processor,  and  an  Intelligence 
Information  Subsystem.  According  to  Army  officials,  the 
choice  was  to  be  made  by  the  end  of  1980,  after  completion 
of  a  study  to  define  functional  requirements. 

Requirements  definition  for  the  advanced  ASAS  is 
scheduled  for  completion  in  September  1982,  after  the  Army 
assesses  BETA  test  results  and  conducts  experiments  with  the 
test  bed  to  further  develop  functional  system  descriptions, 
operational  concepts,  and  doctrine.  Like  the  Air  Force,  the 
Army  requires  the  capability  to  process  several  thousand  mes¬ 
sages  an  hour.  Therefore,  the  Army  faces  the  same  problem  in 
evaluating  current  BETA  test  results  to  determine  if  its  de¬ 
sign  will  provide  adequate  communications  processing  capabil¬ 
ity. 


Army  comments 

In  commenting  on  a  draft  of  this  report,  the  Army  (1) 
disagreed  that  it  should  be  committed  to  using  BETA  to  ful¬ 
fill  its  requirements,  (2)  disagreed  that  it  was  uncertain 
about  its  system  requirements,  and  (3)  objected  to  calling 
the  Technical  Control  and  Analysis  Center  an  automated  files 
management  system. 

The  Army  advised  that  ASAS  requires  functions  in 
addition  to  those  planned  for  the  Tactical  Fusion  Division 
System,  and  that  these  functions  are  not  within  the  scope  of 


the  BETA  development.  Therefore,  BETA  cannot  fulfill  the 
total  ASAS  requirement,  which  includes  processing,  special 
compartmented  information,  control  of  sensors,  and  other 
intelligence  functions.  However,  the  Army  stated  that  it 
intends  to  use  BETA  technology  and  methodology  for  the 
subset  of  ASAS,  which  is  called  collateral  processing,  where 
appropriate.  The  Army  declined  to  use  the  currently  config¬ 
ured  test  bed  as  the  total  baseline  hardware  architecture, 
noting  hardware  development  for  the  Technical  Control  and 
Analysis  Center  and  the  ASAS  Signal  Intelligence  and  Elec¬ 
tronic  Warfare  Subsystem  programs.  However,  we  observed 
that  failure  to  use  the  BETA  system  architecture  for  the 
collateral  processing  subset  will  preclude  using  major  por¬ 
tions  of  the  BETA  software  which  has  already  been  developed 
over  the  past  2  years  and  will  further  preclude  the  early 
fielding  of  an  operational  system.  For  example,  we  noted 
there  would  be  changes  in  software  for  input  and  processing 
of  sensor  messages  and  correlating  data  and  for  presenting 
target  nominations  at  the  operator  terminal. 

The  Army  advised  that  a  version  of  the  Technical  Control 
and  Analysis  Center  will  process  special  compartmented  infor¬ 
mation.  Further,  the  Center  will  provide  for  automatic  re¬ 
cord  traffic  message  inputing,  automatic  extraction  of  data 
from  selected  record  traffic  and  manually  inputed  messages, 
correlation  of  parametric  data,  automated  analysis  routines, 
and  automated  support  to  mission  management.  We  reviewed  the 
status  of  the  Center's  development  and  found  that  while  pre¬ 
viously  described  functions  have  been  specified  and  designed, 
only  a  small  portion  of  the  software  has  been  developed. 
Completion  of  Center  development  is  scheduled  for  mid-1982. 
Subsequently,  an  upgrade  program  is  scheduled  to  add  color 
graphics  for  the  operator  consoles,  which  is  similar  in  capa¬ 
bility  to  the  BETA  operator  terminals. 

NAVY  PLANS  LIMITED  USE 
OF  BETA  TECHNOLOGY 


The  Navy's  involvement  in  the  BETA  project  was  limited 
to  providing  a  sensor  system  for  the  planned  European  demon¬ 
stration  and  investigating  methods  of  communicating  correla¬ 
tion  center  data  between  maritime  and  land-based  forces.  The 
Navy  believes  there  is  a  significant  difference  in  correla¬ 
tion  system  capabilities  required  to  track  highly  mobile 
naval  targets  versus  static  ground  targets  in  a  land  battle. 
Therefore,  the  Navy  believes  that  large  scale  application  of 
BETA  to  support  the  Navy's  requirement  is  not  feasible  and 
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there  is  no  plan  to  utilize  present  BETA-like  hardware  or 
software  in  Navy  correlation  systems.  Navy  involvement  in 
future  BETA  efforts  will  include  participation  in  a  planned 
joint  service  exercise.  The  BETA  post-1980  development  plan 
states  several  potential  scenarios  in  which  a  land-based 
BETA-like  correlation  center  could  be  useful  to  Navy  opera¬ 
tions: 

— In  an  amphibious  operation  during  a  land  battle ,  the 
Navy  could  use  the  land-based  correlation  center  in¬ 
formation  to  coordinate  air  support  and  targeting. 

By  providing  a  ground  situation  display,  the  center 
would  support  the  command  and  control  of  the  amphi¬ 
bious  operation. 

— A  land-based  correlation  center  could  help  direct 
naval  gunfire  support  through  ground  displays  through 
its  target  nomination  capability.  The  ability  to  link 
target  acquisition  sensors  to  gunfire  support  ships 
would  enhance  all-weather,  day/niyht,  standoff  target¬ 
ing  . 

— A  land-based  correlation  center  could  provide  target¬ 
ing  support  for  ship-launched  missiles  against  land 
targets. 

If  the  above  requirements  are  to  be  supported,  ground 
target  nominations  must  be  integrated  into  shipboard  command 
and  control  systems.  At  the  time  of  our  review,  the  Navy  had 
not  developed  a  technical  approach  to  accomplish  this  inte¬ 
gration. 

Although  the  Navy  was  scheduled  to  participate  in  the 
1980  BETA  European  demonstration,  this  testing  would  not  have 
included  the  above  scenarios  because  of  the  demonstration's 
location  in  central  Europe.  Therefore,  BETA'S  ability  to 
support  the  Navy's  involvement  in  joint  operations  would  not 
have  been  evaluated. 

Navy  comments 

In  commenting  on  a  draft  of  this  report,  the  Navy  advised 
that  present  BETA  hardware  and  software  are  similar  to  a  cur¬ 
rent  Navy  operational  correlation  system  tailored  to  maritime 
target  data  processing.  Thus,  present  BETA  technology  does 
not  significantly  improve  current  Navy  operational  capabili¬ 
ties  . 
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The  Navy  agrees  that  BETA-derived  information  on  ground 
targets  should  support  naval  forces,  but  believes  that  it  is 
premature  to  assume  that  BETA'S  ground  target  nominations 
should  be  integrated  into  shipboard  command  and  control 
systems.  The  Navy  agrees  with  the  need  to  define  a  technical 
approach  for  providing  BETA-derived  information  to  its  forces 
and  advises  that  it  will  consider  the  possible  use  of  graphic 
display  terminals  already  in  the  Navy's  inventory. 

MARINE  CORPS  FORESEES 
LIMITED  BETA  APPLICATION 

Current  Marine  Corps  participation  in  the  BETA  project 
consists  of  observing  the  test  program.  Following  the  June 
1978  congressional  direction  to  include  Marine  Corps  partici¬ 
pation  in  the  BETA  project,  it  was  determined  that  the  Marine 
Corps  had  no  real-time  sensor  system  to  interface  with  the 
BETA  test  bed  during  the  planned  European  demonstration. 
Results  of  this  demonstration  were  to  determine  potential  BETA 
application  in  developing  related  Marine  Corps  systems.  We 
found  that  there  was  no  detailed  analysis  of  BETA'S  ability  to 
satisfy  Marine  Corps  intelligence  processing  requirements. 
Nevertheless,  Marine  Corps  officials  advised  that  a  system 
under  development,  called  the  Intelligence  Analysis  Center, 
will  satisfy  its  requirements,  and  there  is  no  plan  to  imple¬ 
ment  BETA.  The  Marine  Corps  plans  to  participate  in  a  joint 
service  exercise  to  evaluate  communications  interoperability 
with  BETA  and  other  command  and  control  systems. 

The  similarity  of  intelligence  needs  in  land  warfare 
raises  a  question  whether  any  substantive  difference  exists 
between  Army  and  Marine  Corps  information  requirements,  and 
the  need  for  the  Marine  Corps  to  continue  development  of  sys¬ 
tems  having  functions  similar  to  those  included  in  BETA. 
Therefore,  the  Marine  Corps  effort  may  nearly  duplicate  the 
BETA  effort  and  continued  development  of  the  Intelligence 
Analysis  Center  could  compound  the  existing  problem  of  soft¬ 
ware  and  equipment  compatibility  and  interoperability  among 
and  between  the  services.  Compatibility  and  interoperability 
of  equipment  and  software  become  extremely  important  during 
crisis  management  and  periods  of  armed  conflict. 

Marine  Corps  comments 

In  commenting  on  a  draft  of  this  report,  the  Marine  Corps 
advised  that  it  has  informally  analyzed  its  correlation  system 
requirements  and  determined  that  there  is  no  current  require¬ 
ment  for  BETA  capabilities.  However,  it  will  continue  to 
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monitor  results  of  the  BETA  project  and  will  consider  using 
developed  technology  to  meet  future  requirements. 

The  Marine  Corps  believes  that  there  are  substantive 
differences  between  Army  and  Marine  Corps  information  re¬ 
quirements  and  the  methods  of  handling  information.  This  is 
because  it  operates  in  an  amphibious  warfare  environment  and 
it  manages  information  at  a  different  organizational  level 
than  the  Army. 

The  Marine  Corps  disagreed  that  development  of  the 
Intelligence  Analysis  Center  was  redundant  to  a  BETA-like 
system.  The  Center's  function  is  to  provide  a  detailed,  com¬ 
prehensive  intelligence  data  base  and  is  not  intended  to  han¬ 
dle  raw  sensor  data.  Instead,  sensor  data  processing  and 
correlation  will  be  performed  by  the  Marine  Tactical  Combat 
Operations  System,  currently  under  development.  We  were  ad¬ 
vised  that  a  test  bed  for  this  system  is  being  developed  and 
BETA  software  has  been  requested  for  use  in  this  effort. 

Using  the  test  bed,  the  Marine  Corps  intends  to  determine  the 
applicability  of  BETA-derived  technology  to  Marine  Corps  auto¬ 
mated  data  processing  systems. 
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CHAPTER  3 


BETA  CAPABILITIES  WERE  NOT  SUFFICIENTLY 
DEVELOPED  FOR  EUROPEAN  TESTING  IN  1980 

BETA  test  bed  capabilities  have  not  been  sufficiently 
developed  to  warrant  field  testing  in  Europe.  Although 
BETA  is  heavily  dependent  on  software  to  perform  its  func¬ 
tions,  the  software  was  not  developed  under  an  orderly 
process.  We  found  that  management  actions  taken  to  meet 
scheduled  milestones  violated  sound  software  development 
practices.  Further,  there  are  serious  technical  problems 
and  the  test  bed  performance  does  not  meet  contract 
specifications. 

As  of  July  1980,  BETA  had  not  successfully  completed 
system  integration  tests.  Laboratory  testing  has  disclosed 
that  the  test  bed  does  not  (1)  function  correctly,  (2)  proc¬ 
ess  the  required  volume  of  sensor  messages,  or  (3)  process 
the  data  within  required  response  times.  Further,  testing 
was  not  sufficient  to  evaluate  whether  BETA'S  design  could 
meet  contractual  requirements.  Considerable  corrective 
action  will  be  needed  before  the  BETA  project  can  provide  an 
acceptable  software  baseline  for  early  fielding  of  an  opera¬ 
tional  system. 

BETA  CAPABILITIES  REDUCED  TO 
MEET  SELF-IMPOSED  TIME  SCHEDULE 


BETA  development  requirements  were  initially  defined 
in  a  Request  For  Proposal  issued  to  industry  in  November 
1977.  Required  automated  capabilities  were  to  include: 

— Correlation  centers  established  at  three  echelons: 

Air  Force  tactical  air  control,  Army  Corps,  and  Army 
division  levels. 

— A  capability  to  simultaneously  process  the  input  from 
15  sensors  plus  other  reports  to  a  maximum  of  4,000 
reports  an  hour. 

— Specific  system  response  times  for  performing  major 
functions,  such  as  correlating  data,  processing  data 
through  the  system,  and  responding  to  operator 
requests  for  information.  Data  correlation  involves 
comparing  new  sensor  reports  with  previous  reports 
on  file  to  update  target  status,  and  associating  and 
displaying  data  for  specific  areas  of  interest. 


— A  capability  to  generate  color  graphic  and  alphanume¬ 
ric  tactical  situation  displays  on  operator  terminals 
and  an  ability  to  transmit  displayed  data  to  other 
operator  terminals  and  between  correlation  centers. 

On  December  4,  1978,  the  system  specification  was  re¬ 
vised  to  define  functional  capability  requirements  in  more 
detail  and  to  provide  a  plan  for  verifying  that  test  bed 
performance  complied  with  stated  requirements.  Project  offi¬ 
cials  believe  that  this  revised  specification  required  more 
capability  than  the  original  Request  For  Proposal. 

After  the  contractor  revealed  that  the  full  test  bed 
capability  defined  by  the  contract  could  not  be  accomplished 
within  estimated  program  cost  and  time  schedule  milestones 
for  the  1980  European  demonstration,  the  BETA  project  was 
restructured  to  fit  the  schedule  and  available  funds.  Accord¬ 
ingly,  the  system  specification  was  again  revised  on  January 
26,  1979,  to  reflect  the  reduced  scope  of  the  project.  (See 
app.  V  for  examples.)  The  test  bed  configuration  represented 
by  this  specification  was  dubbed  "Bare  Bones  BETA"  by  the  proj 
ect  office. 

In  August  1979  the  project  office  directed  additional 
deletions  in  automated  functional  capabilities  after  deter¬ 
mining  this  action  was  needed  to  keep  the  project  on  schedule. 
(See  app.  VI  for  examples.)  The  project  office  designated 
this  configuration  "Bare  Bones  BETA  Minus."  Project  officials 
believed  that  these  software  functions  were  not  required  for 
the  1980  European  demonstration. 

Generally  speaking,  the  changes  in  requirements  occurred 
in  three  areas: 

— Elimination  of  the  Army  division  correlation  center. 
Instead,  remote  display  systems  which  are  essentially 
operator  terminals,  were  substituted  to  partially 
offset  the  loss  of  correlation  center  capability. 

— Elimination  of  selected  but  necessary  automated  func¬ 
tions  to  assist  in  processing  a  large  volume  of  sensor 
reports. 

— Deletion  of  selected  automated  functions  to  assist 
system  operators  in  managing  sensors. 

According  to  project  plans,  the  deleted  requirements  were  to 
be  reinstated  during  the  next  project  phase.  As  evidenced 
by  a  February  1979  BETA  project  director  memorandum,  the 
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changes  in  requirements  which  defined  the  Bare  Bones  BETA 
configuration  were  made  primarily  to  meet  the  scheduled 
1980  European  demonstration  time  schedule  as  directed  by  OSD. 
Even  with  the  changes,  he  considered  that  meeting  the  sche¬ 
dule  presented  a  very  high  risk.  He  believed  that  deletion 
of  the  division  correlation  center  was  a  major  loss  of  planned 
capability  and  that  some  of  the  deleted  software  requirements 
were  significant.  Nevertheless,  he  considered  the  Bare  Bones 
BETA  configuration  to  have  sufficient  capability  to  support 
the  European  demonstration.  This  is  because  it  would  provide 
sensor  interfaces,  message  handling  procedures,  multiuser 
sensor  data  distribution,  a  data  base  and  displays  to  support 
manual  analysis,  and  remote  dissemination  of  information.  He 
believed  that,  considering  the  low  sensor  message  load  ex¬ 
pected  during  the  European  exercise,  Bare  Bones  BETA  would  be 
capable  of  other-aided  sensor  data  correlation,  resulting  in 
near  realtime  target  location. 

We  discussed  the  impact  of  the  deleted  requirements  with 
officials  from  Army  and  Air  Force  activities  responsible  for 
defining  system  requirements.  They  agreed  that  deleted  hard¬ 
ware  and  software  requirements  were  significant  reductions  in 
test  bed  capabilities  and  believed  that  it  was  desirable  to 
include  these  requirements  in  the  current  configuration. 

LABORATORY  TESTING  DISCLOSED 
PERFORMANCE  PROBLEMS 


The  BETA  project  plan,  dated  May  8,  1979,  established 
a  series  of  major  test,  training,  and  evaluation  milestones 
leading  up  to  the  1980  European  demonstration.  After  these 
events  were  held,  BETA  officials  concluded  that  BETA  failed 
major  test  phases  and  was  not  ready  to  proceed  with  the 
European  demonstration.  Overall,  the  test  results  showed 
that  the  Bare  Bones  BETA  Minus  test  bed  had  serious  software 
discrepancies  which  precluded  it  from  functioning  correctly. 
Further,  it  cannot  process  the  specif  d  volume  of  sensor 
data  nor  process  the  data  within  spec  .fied  response  times. 
Also,  we  found  that  adequate  documentation  was  not  prepared 
to  validate  test  results,  and  system  integration  tests  and 
training  exercises  were  started  before  previous  test  phases 
were  successfully  completed.  Further,  configuration  control 
was  lost  over  software  changes  ro.de  to  correct  discrepancies 
disclosed  by  testing.  The  following  sections  describe  the 
objectives  and  results  of  the  three  major  testing  milestones: 
correlation  center  integration,  system  integration,  and 
command  post  exercises. 
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Correlation  center  integration  testing 

This  test  phase  consisted  of  integrating  and  testing 
the  functional  capabilities  of  the  four  major  software  seg¬ 
ments:  applications,  communications,  operator  terminal,  and 
system  support.  This  integration  activity  consisted  of  in¬ 
troducing  new  software  components  into  the  software  test 
configuration  to  verify  that  each  computer  processing  mode 
could  execute  functional  tasks  without  significant  anomalies. 

According  to  correlation  center  integration  test  plans, 
test  results  were  to  be  documented  to  validate  that  system 
functional  requirements  were  met.  Further,  discrepancies 
identified  during  this  test  phase  were  to  be  corrected  before 
system  integration  testing  was  started.  We  found  that  the 
contractor  did  not  meet  either  of  these  two  conditions. 

It  should  be  noted  that  this  test  disclosed  1,258  soft¬ 
ware  discrepancies,  some  of  which  were  considered  signifi¬ 
cant  by  the  BETA  Project  Office.  At  the  time  of  the  system 
integration  test,  216  of  these  discrepancies  were  unresolved, 
17  were  deferred  for  further  study,  65  were  logged  pending 
classification,  and  the  remaining  960  were  closed. 

Examples  of  significant  software  discrepancies  noted 
during  testing  included  the  following: 

— Communications  segment.  Heavy  message  traffic  results 
in  transmission  errors,  illegal  message  routing,  and 
total  system  collapse.  There  are  also  frequent  trans¬ 
mission  errors  and  loss  of  synchronization  when  send¬ 
ing  messages  to  the  operator  terminals. 

— Operator  terminal  segment.  Operator  terminals 

frequently  lockout  and  require  reload.  Operator  cannot 
qualify  a  query  by  location  error,  target  nomination 
status,  or  targetability .  Also,  a  radio  query  cannot 
be  qualified  by  frequency.  Canceling  an  in-process 
query  sometimes  results  in  display  of  incorrect  infor¬ 
mation.  The  same  query  at  different  terminals  results 
in  display  of  different  information. 

— Data  storage  and  retrieval  segment.  Under  heavy  load 
conditions  this  segment  fails  to  respond  properly  to 
open  calls  for  information.  This  causes  the  entire 
BETA  process  to  shut  down. 
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System  integration  tests 

The  objective  of  system  integration  testing  is  to  verify 
that  the  test  bed  meets  specified  system  performance  require¬ 
ments.  This  testing  is  being  conducted  at  the  contractor's 
facility  in  Redondo  Beach,  California.  A  demonstration  was 
scheduled  for  May  29,  1980,  to  show  top  management  that  this 
phase  was  successfully  completed. 

We  observed  the  May  29  demonstration  and  noted  that 
BETA  did  not  function  properly.  Project  officials  concurred 
with  our  observation.  For  example,  half  of  the  operator 
terminals  were  inoperable  or  appeared  unable  to  communicate 
with  the  correlation  centers.  The  terminals  which  were  oper¬ 
able  were  unable  to  execute  some  of  the  basic  information 
queries  to  the  correlation  centers.  At  the  time  of  our 
visit,  data  could  not  be  obtained  on  (1)  system  availability, 
(2)  response  time  in  executing  functions,  or  (3)  the  capabi¬ 
lity  to  process  and  correlate  the  required  volume  of  sensor 
messages.  This  was  because  this  test  phase  was  just  starting 
instead  of  ending  as  scheduled  and  no  data  had  been  accumu¬ 
lated.  The  numerous  hardware  and  software  problems  in  getting 
the  system  to  function  resulted  in  only  limited  integration 
tests  being  performed.  The  project  office  now  estimates  that 
this  test  phase  will  not  be  completed  until  February  1981. 

In  addition  to  observing  the  demonstration,  we  asked  the 
contractor  to  provide  documentation  showing  the  results  of 
correlation  center  integration  testing.  We  were  advised  that 
the  required  documentation  had  not  been  prepared  in  the  haste 
to  meet  the  schedule  for  European  testing.  Therefore,  pro¬ 
ject  officials  were  unable  to  verify  that  system  functional 
requirements  were  met.  However,  we  were  shown  raw  test  case 
data  for  several  processing  modes  which  indicated  the  testing 
was  being  performed. 

Lack  of  complete  documentation  also  created  another 
problem.  When  the  contractor's  software  test  team  modified 
the  software  to  correct  problems  disclosed  by  testing,  it  did 
not  fully  document  the  changes.  Therefore,  the  contractor 
cannot  readily  determine  how  this  version  is  really  designed. 
This  makes  it  very  difficult  to  identify  the  causes  of  new 
problems  and  to  implement  a  design  change.  Project  officials 
characterized  this  situation  as  "loss  of  configuration  control" 
and  believe  that  this  problem  must  be  corrected  before  the 
software  can  provide  an  acceptable  baseline  for  engineering 
development. 
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Command  post  exercise 

The  command  post  exercise  was  held  on  July  7,  1980. 

Test  bed  equipment  was  located  both  at  TRW's  laboratory  facil 
ity  and  at  Camp  Pendleton,  California.  According  to  the 
project  plan,  the  exercise  objective  was  to  provide  an  ini¬ 
tial  user  evaluation  of  BETA  in  a  field  environment,  test 
technical  interfaces  of  BETA  subsystems,  and  evaluate  how 
well  military  personnel  were  trained  to  operate  the  system. 
However,  in  view  of  the  problems  experienced  during  system 
integration  tests,  specific  criteria  were  developed  by  the 
project  office  which  oriented  the  exercise  objective  toward 
determining  if  BETA  had  sufficient  technical  capability  to 
participate  in  the  European  demonstration.  The  criteria 
described  the  functional  capabilities  that  had  to  be  demon¬ 
strated  before  project  management  would  approve  shipping  the 
test  bed  to  Europe.  Essentially,  BETA  had  to  successfully 
complete  system  integration  tests  and  demonstrate  specified 
functional  capabilities  when  processing  1,000  simulated  sen¬ 
sor  messages  an  hour  (versus  the  specified  rate  of  4,000 
messages  an  hour). 


We  also  observed  the  command  post  exercise  and  found 
that  test  bed  performance  did  not  pass  the  criteria  estab¬ 
lished  by  the  project  office.  Many  automated  functions 
were  unreliable  and  system  hardware  availability  was  not  ade¬ 
quate.  The  project  office  believes  that  there  are  signif¬ 
icant  software  problems  affecting  (1)  capability  to  query  the 
system  for  information,  (2)  operator  terminal  usability  and 
availability,  and  (3)  communications  reliability. 

After  the  exercise,  the  contractor  was  unable  to  provide 
test  data  showing  that  sensor  reports  processed  during  the 
exercise  were  properly  correlated  and  file  records  were  cor¬ 
rectly  updated.  Therefore,  project  officials  did  not  know  if 
the  tactical  situation  reports  being  displayed  were  accurate. 
Previous  tests  identified  numerous  correlation  software  dis¬ 
crepancies  and  data  is  needed  to  verify  that  software  revi¬ 
sions  have  corrected  the  discrepancies. 

We  discussed  the  operator  training  program  with  training 
instructors  and  were  advised  that  the  test  bed  was  too  un¬ 
stable  to  train  military  operators  for  the  European  demonstra 
tion.  They  believe  that  up  to  4  additional  weeks  of  training 
would  have  been  needed  before  the  operators  could  perform  in 
the  European  demonstration.  During  June  1980,  the  project 
office  attempted  to  train  53  terminal  operators  at  TRW;  how¬ 
ever,  the  test  bed  did  not  operate  well  enough  to  provide 


adequate  terminal  time  for  training  until  the  last  week  in 
June.  By  that  time,  41  of  the  53  trainees  had  departed.  The 
12  remaining  trainees  were  retained  to  participate  in  the 
exercise  and,  therefore,  received  additional  training. 

A  project  official  advised  that  only  limited  performance 
testing  was  held  before  the  exercise  because  the  system  did 
not  work  well  enough  to  perform  the  tests  required  by  the  sys¬ 
tem  integration  test  plan.  Further,  he  advised  that  due  to 
software  problems,  the  test  bed  was  unable  to  operate  under  a 
sensor  message  load  exceeding  1,300  messages  an  hour. 

Project  officials  believe  that  system  integration  tests 
must  be  continued  to  determine  whether  the  test  bed  design  can 
adequately  process  the  required  sensor  load,  and  if  not,  to 
identify  needed  changes  to  achieve  this  capability.  They  be¬ 
lieve  that  the  effort  will  require  6  to  8  months  of  additional 
testing . 

CONTRACTOR  COMMENTS 

TRW,  Inc.,  has  commented  on  a  draft  of  this  report  and 
advised  that  it  considers  this  report  to  be  an  objective  and 
constructive  review  of  a  difficult  technological  undertaking. 
Further,  the  contractor  believes  that  it  has  recently  made 
progress  in  correcting  some  technical  problems.  The  following 
detailed  observations  were  also  provided  by  TRW,  Inc. 

— The  program  objective  of  developing  a  highly  technical 
system  within  2-1/2  years  was  extremely  ambitious,  but 
achievable.  Due  to  slow  program  start-up  and  delays 
in  completing  system  design,  significant  schedule  com¬ 
pression  in  later  portions  of  the  program  resulted. 
Further,  the  program  development  activities  were  re¬ 
structured  to  achieve  the  European  testing  milestone 
in  September  1980.  This  caused  development  tasks  to 
be  performed  in  parallel  rather  than  following  a  slower 
paced  and  less  risky  sequential  procedure.  Also,  it 
became  necessary  to  defer  all  tasks  which  were  not 
essential  to  the  European  demonstration,  including  soft¬ 
ware  documentation. 

— The  specified  requirement  to  process  4,000  sensor 
reports  an  hour  is  questionable,  particularly  with 
tight  cost  and  schedule  restrictions. 
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— Examples  cited  as  communication  software  discrepancies 
were  also  related  to  other  factors,  such  as  hardware 
design  problems  and  operator  errors. 

— Standard  configuration  control  procedures  were  main¬ 
tained  on  all  major  segments  except  the  application's 
software,  which  was  approximately  one-sixth  of  the 
‘total  software  developed.  This  problem  has  been  cor¬ 
rected. 

— Operator  terminal  availability  was  the  most  significant 
problem  which  prevented  BETA  from  participating  in  the 
European  exercise.  Numerous  design  changes  have  been 
identified  and  tested,  and  now  terminal  operation  is 
extremely  stable. 

We  are  presently  monitoring  contractor  efforts  to  correct 
software  and  hardware  technical  problems.  Completion  of  test¬ 
ing  to  verify  correction  of  reported  discrepancies  is  sche¬ 
duled  for  February  1981. 
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CHAPTER  4 

BETA  PROJECT  HAS  SIGNIFICANT  COST  GROWTH 

The  BETA  project  was  estimated  to  cost  $98  million 
through  completion  in  fiscal  year  1984.  In  June  1980  project 
officials  estimated  that  the  first  project  phase  would  cost 
$59  million,  including  $46.5  million  for  the  system  contrac¬ 
tor's  effort.  The  $39  million  for  the  post-1980  development 
phase  included  $9.6  million  for  inflation.  The  schedule  below 
shows  estimated  funding  contributions  from  Defense  agencies 
involved  in  the  project. 


Funding  contribution 


Agency 

Current  phase 

Post-1980 

Total 

Defense  Advanced 
Research  Projects 
Agency 

$10. 80 

$  0.00 

$10.80 

Department  of 
Army 

the 

23.60 

20.80 

44.40 

Department  of 
Navy 

the 

3.00 

2.20 

5.20 

Department  of 
Air  Force 

the 

21.10 

14.50 

35.60 

Marine  Corps 

0.02 

0.05 

0.07 

National  Security 
Agency 

0.30 

0.00 

0.  30 

Agency  to  be 
determined 

0.00 

1.40 

1.40 

Total 

$58.82 

$38.95 

$97.77 

When  the  cost  plus  award  fee  contract  was  signed  with  TRW, 
Inc.,  in  March  1978  to  develop  the  test  bed  for  a  September 
1980  European  demonstration,  the  project  office  estimated  the 
cost  to  be  $21.2  million.  As  of  May  1980,  estimated  contract 
costs  have  grown  $25.3  million.  1/  This  cost  growth  would  have 
been  even  higher  if  development  of  various  software  functions 
and  acquisition  of  hardware  items  had  not  been  deferred  until 


1/Includes  $3  million  in  additional  requirements  added  by 
the  project  office. 
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the  next  phase  of  the  project.  Project  office  personnel 
attributed  most  of  the  cost  growth  to  the  contractor's  diffi¬ 
culty  in  (1)  initially  understanding  functional  requirements, 
(2)  obtaining  experienced  computer  professionals  in  Califor¬ 
nia,  and  (3)  obtaining  acceptable  hardware  and  software  from 
subcontractors . 

In  our  March  1980  report  to  the  Chairman,  Subcommittee 
on  Defense,  House  Committee  on  Appropriations  (LCD-80-38),  we 
stated  that  the  cost  growth  totaled  $20.1  million.  About  2 
months  later,  project  officials  estimated  that  the  cost  growth 
would  total  $25.3  million.  Project  officials  stated  that  the 
additional  $5.2  million  would  be  needed  to  correct  both  hard¬ 
ware  and  software  discrepancies  disclosed  during  laboratory 
testing. 


CHAPTER  5 


THE  CONGRESS  REDIRECTED  THE  BETA  PROJECT 

In  our  March  3,  1980,  report,  we  questioned  the  project's 
readiness  for  a  European  test  and  recommended  that  several 
options  be  considered  before  authorizing  additional  funds. 
These  options  included  delaying  the  European  test  until  more 
comprehensive  field  tests  could  be  conducted,  terminating 
the  project,  or  deferring  approval  of  additional  funding  un¬ 
til  more  current  and  reliable  test  results  become  available. 

OSD  subsequently  requested  the  Congress  to  approve  the 
reprograming  of  $6.7  million  to  cover  known  and  anticipated 
cost  growth  for  completing  the  initial,  but  degraded  phase 
of  the  project.  After  the  Congress  questioned  OSD  about  our 
concerns,  in  April  1980  the  House  Permanent  Select  Committee 
on  Intelligence  advised  the  Secretary  of  Defense  that  $3.7 
million  of  the  requested  $6.7  million  would  be  deferred  until 
June  1980,  when  the  results  of  the  system  integration  tests 
could  be  assessed.  Further,  the  Committee  advised  that  con¬ 
tinued  funding  of  BETA  would  be  contingent  on  the  successful 
completion  of  the  European  demonstration  or  the  presentation 
of  an  acceptable  alternative  test  demonstration  plan. 

In  June  1980  the  House  Committee  on  Appropriations  and 
the  House  Permanent  Select  Committee  on  Intelligence  learned 
that  system  integration  test  results  were  unsatisfactory. 

The  reprograming  request  was  approved  subject  to  certain  con¬ 
ditions.  The  Committees  noted  BETA'S  development  schedule 
slippage,  inordinate  cost  increases,  reduced  capabilities, 
and  poor  performance  during  testing.  Therefore,  the  Commit¬ 
tees  asked  that  the  reprogramed  money  be  used  to  complete  the 
software  effort  and  to  correct  system  deficiencies.  Further, 
future  project  efforts  were  directed  toward  acquiring  a  common 
fusion  system  for  the  Army  and  Air  Force  at  the  earliest  date 
possible.  Instead  of  continuing  with  a  technology  demonstra¬ 
tion  project,  the  Department  of  Defense  was  requested  to 
provide  the  Congress  with  a  plan  1/  showing  milestones  and 
funding  requirements  for  joint  service  development  of  a 
fielded  system,  building  on  BETA  software  and  making  maximum 
use  of  common  hardware. 


1/The  Secretary  of  Defense  provided  the  plan  to  the  Congress 
in  October  1980.  The  Subcommittee  on  Defense,  House 
Committee  on  Appropriations,  asked  us  to  thoroughly  evaluate 
this  plan  following  its  submission  to  the  Congress. 
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CHAPTER  6 


CONCLUSIONS,  RECOMMENDATIONS,  AND  AGENCY  COMMENTS 
CONCLUSIONS 

Although  the  BETA  project  did  not  successfully  meet  its 
goals,  time  and  money  were  heavily  invested  in  developing  the 
BETA  technology.  The  services  require  intelligence  correla¬ 
tion  system  capabilities,  and  we  believe  that  the  investment 
in  BETA  should  be  maximized.  BETA  capabilities  have  not 
been  sufficiently  developed  and  tested  to  provide  a  baseline 
for  early  fielding  of  an  operational  system.  Therefore,  we 
believe  that  several  months  of  additional  testing  would  be 
useful  in  achieving  this  goal.  As  a  minimum,  this  testing 
would  provide  sufficient  technical  information  for  deciding 
on  how  to  proceed  with  the  engineering  development  effort 
directed  by  the  Congress.  For  example,  additional  testing 
could  identify  fundamental  changes  needed  in  BETA'S  software 
to  achieve  acceptable  performance  or  it  could  show  that  start¬ 
ing  over  with  a  different  design  is  warranted.  Testing  con¬ 
ducted  so  far  shows  that: 

— The  test  bed  does  not  have  the  capability  to  process 
the  required  volume  of  sensor  data.  This  capability 
is  a  critical  element  in  the  operational  requirement 
defined  by  OSD.  Problems  with  software  precluded 
testing  the  system  beyond  33  percent  of  the  specified 
message  load  level.  Therefore,  the  project  office  was 
unable  to  validate  the  test  bed's  ability  to  process 
specified  sensor  message  loads. 

— The  software  package  has  serious  discrepancies  which 
preclude  the  system  from  either  functioning  correctly 
or  operating  at  specified  design  levels.  Further, 
adequate  software  documentation  was  not  prepared  to 
validate  test  results,  and  the  project  proceeded  into 
the  system  integration  test  phase  before  successfully 
completing  previous  test  phases. 

— While  BETA  is  designed  for  automated  correlation  of 
sensor  data  inputs,  some  of  the  automated  functions  to 
assist  system  operators  in  controlling  the  high  volume 
of  data  and  managing  sensors  were  deleted  as  require¬ 
ments.  Since  these  functions  must  be  performed  manu¬ 
ally,  it  takes  longer  to  nominate  targets. 
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In  addition  to  software  development  problems  and  reduced 
performance  requirements,  the  project  also  experienced  consid- 
erable  cost  growth — TRW's  estimated  development  cost  has  more 
than  doubled  since  the  contract  was  awarded  and  now  totals 
over  $46  million.  We  believe  that  pressure  from  OSD  manage¬ 
ment  to  field  test  BETA  in  Europe  by  September  1980  contrib¬ 
uted  significantly  to  project  development  problems.  In  our 
opinion,  a  software-dependent  system,  such  as  BETA,  should 
have  been  developed  under  an  orderly  process  that  is  event- 
oriented,  instead  of  driven  by  a  time  schedule. 

The  services  have  already  invested  almost  $60  million 
in  BETA  development  to  carry  out  a  field  exercise  in  Europe. 

If  the  project  had  proceeded  to  the  next  phase  as  planned, 
the  total  investment  would  soon  approach  the  $100  million 
threshold  used  by  OSD  for  classifying  projects  as  a  major 
weapon  system  acquisition.  Although  the  BETA  project  started 
out  as  a  technology  demonstration,  the  research  and  develop¬ 
ment  effort  now  being  performed  to  implement  project  objec¬ 
tives  is  characteristic  of  a  weapon  system's  advanced 
development  phase.  Therefore,  the  services  should  resolve 
their  basic  requirement  questions  as  early  as  possible  so 
that  management  can  effectively  proceed  with  a  joint  service 
project. 

In  view  of  congressional  direction  to  form  a  joint 
service  correlation  system  project,  we  believe  that  the  prin¬ 
cipal  direction  of  BETA  efforts  in  the  immediate  future  should 
be  to  support  the  early  fielding  of  a  joint  service  tactical 
correlation  system.  Therefore,  a  reasonable  attempt  should  be 
made  to  correct  deficiencies  which  presently  exist  with  BETA 
software  so  that,  when  combined  with  computer  hardware  that 
meets  military  specifications,  it  can  be  used  to  the  maximum 
extent  possible  in  an  operational  system. 

RECOMMENDATIONS 


We  recommend  that  the  Secretary  of  Defense  include  the 
following  provisions  in  the  BETA  project  plan: 

— The  principal  objective  of  future  BETA  efforts  should 
be  to  support  the  early  fielding  of  a  joint  service 
tactical  echelon  correlation  system  to  meet  Army  and 
Air  Force  operational  requirements  for  the  1980s. 

— An  overall  schedule  for  system  engineering  develop¬ 
ment  and  early  fielding,  as  well  as  corresponding 
funding  requirements.  Further,  this  acquisition  should 
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be  managed  by  a  single  project  office,  responsible 
for  accommodating  both  Army  and  Air  Force  require¬ 
ments  and  for  maintaining  system  configuration 
control. 

— An  orderly,  well-planned,  software  development  pro¬ 
cess  with  progress  based  on  attainment  of  performance 
goals,  instead  of  a  time  schedule.  This  process 
should  start  with  a  6  to  8  month  "f ind-and-f ix"  phase 
to  (1)  correct  rect  major  software  discrepancies  and 
(2)  attempt  bringing  the  current  test  bed  up  to  speci¬ 
fied  performance  levels.  After  this  phase  is  success¬ 
fully  completed,  as  evidenced  by  testing,  service 
experimentation  with  the  test  bed  should  continue  to 
identify  and  develop  service-unique  or  advanced  capa¬ 
bilities,  which  can  be  added  during  engineering  devel¬ 
opment  by  future  software/hardware  upgrades. 

— Firm  Army  commitment  to  utilize  the  BETA  system  archi¬ 
tecture  to  fulfill  a  portion  of  its  tactical  fusion 
requirements  so  that  the  joint  project  can  make  maxi¬ 
mum  use  of  existing  software  and  common  hardware. 

— Navy  definition  of  a  technical  approach  for  integrat¬ 
ing  BETA'S  ground  target  designations  into  shipboard 
command  and  control  systems. 

— Marine  Corps  analysis  comparing  its  correlation  system 
requirements  with  planned  BETA  capabilities,  and  subse¬ 
quently,  a  plan  that  defines  how  BETA  can  be  used  to 
satisfy  those  requirements. 

— An  acquisition  strategy  that  will  maximize  use  of  BETA 
software  in  the  engineering  development  model  of  the 
joint  correlation  system  to  the  extent  technically 
feasible.  Essentially,  this  will  require  the  contrac¬ 
tor  to  provide  computer  hardware  which  meets  military 
specifications  and  is  compatible  with  BETA  software. 

AGENCY  COMMENTS 

The  Department  of  Defense  has  suggested  that  we  clarify 
statements  concerning  the  services'  intended  use  of  BETA 
technology. 

— The  Army  intends  to  use  BETA  technology  where  appro¬ 
priate.  However,  it  declined  to  make  a  commitment  at 
this  time  to  use  the  BETA  system  architecture,  and  it 
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wishes  to  consider  the  applicability  of  another  system 
under  development. 

-The  Navy  agrees  with  the  need  to  define  a  technical 
approach  for  providing  information  on  ground  targets 
to  its  forces/  but  believes  that  it  is  premature  to 
assume  that  BETA'S  ground  target  nominations  should  be 
integrated  into  shipboard  command  and  control  systems. 

-The  Marine  Corps  advised  that  it  will  evaluate  the 
applicability  of  BETA  technology  to  a  system  currently 
under  development. 
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APPENDIX  I 


APPENDIX  I 


Concents  on  GAO  Draft  Report  dated  October  20,  1980,  "The  BETA  Project:  An 

Evaluation  of  Defense  Efforts  to  Develop  an  Automated  System  for  Managing 

Battlefield  Intelligence  Data"  (GAO  Code  941192)  (OSD  Case  05395-A) 

1.  Page  111,  lines  14-22 

a.  Draft  -  Prior  to  Congressional  direction  to  form  a  joint  service 
project,  the  Air  Force  was  the  only  service  committed  to  using  the 
BETA  design  and  sof tware. . . . .The  Amy  planned  further  test  bed 
experimentation  while  it  continued  analyzing  its  correlation  system 
requirements. 

b.  Comment:  Paragraph  is  misleading  in  that  comparability  between  the 
Army's  All  Source  Analysis  System  (ASAS)  and  the  Air  Force's  Automated 
Tactical  Fusion  Division  (ATFD)  is  not  as  simple  as  Implied.  AFTD,  as 
a  collateral  (non-compartmented)  processing-only  operation,  can  readily 
use  BETA  since  it  too  relates  to  collateral  processing  and  reporting. 
The  Army  has  stated  that  it  intends  to  use  the  BETA  technology  and 
methodology  for  that  subset  of  the  ASAS  which  pertains  to  the  colla¬ 
teral  process.  However,  it  must  be  reiterated  that  the  ASAS  must 

also  process  special  compartmented  information,  control  organic  sensors, 
and  perform  associated  intelligence  and  OPSEC  functions  which  were  not 
within  the  scope  of  the  BETA  development. 

2.  Page  iii,  Last  Sentence 

a.  Draft  -  The  Navy  and  Marine  Corps  foresee  very  limited  application  of 
BETA  technology  to  their  own  projects. 

b.  Comment :  Future  BETA  correlation  technology  may  have  application  to 
Navy  systems.  Present  BETA  technology  does  not  significantly  improve 
upon  that  utilized  in  operational  Navy  correlation  systems  tailored 
to  processing  of  maritime  target  data. 

c.  Recommendation:  Insert  "present"  between  "of"  and  "BETA." 

3.  Page  iv,  last  sentence 

a.  Praf t  -  The  plan  should  contain  "a  firm  Army  commitment  that  will  use 
a  militarized  version  of  BETA  to  fulfill  its  requirements." 

b.  Comment :  Do  not  agree.  BEXA  cannot  fulfill  all  of  the  ASAS  require¬ 
ments  as  BETA  project  only  encompassed  collateral  intelligence  pro¬ 
cessing  and  reporting.  Additionally,  the  term  '"Militarized  version 

of  BETA"  connotes  acceptance  of  the  commercial  hardware  design  ignoring 
our  hardware  development  in  the  Technical  Control  and  Analysis  (TCAC) 
and  ASAS  SIGINT/EW  subsystem  programs.  BETA  technology  will  be 
evaluated  and  utilized  where  appropriate;  however,  we  cannot  agree  to 
acceptance  of  a  currently  configured  test  bed  as  our  total  baseline 
hardware  architecture.  This  can  only  be  ascertained  by  the  Program 
Manager  in  the  evolution  of  the  ASAS/ATFD  systems. 
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4.  Page  V,  First  Paragraph/Page  35,  Line  11 

a.  Draft  -  Navy  definition  of  a  technical  approach  for  Integrating 
BETA'S  ground  target  noainatlons  Into  ahlpboard  conmand  and  control 

ay  sterna. 

b.  Cogent i  Shipboard  systems,  not  necessarily  all  available  on  a  given 
ship.  Include  those  categorised  as  Connand  and  Control,  Conbat  Direction, 
and  Intelligence  Support.  It  Is  considered  prenature  to  assume  BETA'S 
ground  target  nominations  should  be  Integrated  Into  shlpboerd  connand 
and  control  systems. 

c.  Recommendation:  Replace  sentence  with:  "Navy  definition  of  a  technical 
approach  for  providing  BETA  derived  Information  to  supporting  Naval  forces." 

5.  Page  V,  Recommendation 

a.  Draft  -  Marine  Corps  analyses  comparing  its  correlation  system  require¬ 
ments  with  planned  BETA  capabilities,  end  subsequently,  a  plan  that 
defines  how  BETA  can  be  used  to  satisfy  these  requirements. 

b.  Consent :  The  Marine  Corps  has  informally  accomplished  this  task. 

Technical  advisors  have  determined  that  there  la  no  present  require¬ 
ment  for  BETA  capabilities,  however,  the  technology  continues  to  be 
monitored.  The  lack  of  the  sensor  assets  which  contribute  to  BETA  make 
its  use  Impractical  by  the  Marine  Corps. 

c.  Rcconmendation:  Delete  subject  paragraph. 

6.  Page  7 ,  lines  5-8 

a.  Draft  -  Significant  research  and  development  funds  were  Invested  In  the 
BETA  project  without  adequate  Service  commitment  to  directly  apply  the 
technology  to  ongoing  or  planned  correlation  center  developments. 

b.  Comment;  Statement  Is  Ms  leading.  Both  the  BETA  Project  Plan  and  the 
Post  80  Addendum  (which  were  concurred  In  by  the  services  and  approved 
by  OSD)  state  that  the  BETA  project  will  develop  procedures  and  processes 
for  the  correlation  of  sensor  Inputs  and  target  nominations.  They  further 
state  that  these  software  and  procedures  will  be  utilized  to  support 
fielding  of  service  systems.  The  Army  has  supported  these  objectives 
throughout  project  evolution  and  fully  Intends  to  utilise  the  BETA 
technology  along  with  AS  AS  SIGINT  EV  subsystem  and  Technical  Control 

and  Analysis  Center  (TCAC)  technology,  In  the  development  of  our  ASAS 
program. 
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7.  Pages  7,  lines  11-13 

a.  Draft  -  The  Army  was  uncertain  about  its  system  requirements  and 
was  only  committed  to  further  test  bed  experimentation. 

b.  Comment;  Statement  is  misleading.  The  current  Letter  of  Agreement 
(LOA)  and  the  recently  completed  functional  system  description 
describe  the  All  Source  Analysis  System  (ASAS)  requirements  which 
will  be  formalized  into  a  final  ROC.  Additionally,  the  ASAS  requires 
both  collateral  (BETA)  and  special  compartaented  information  proces¬ 
sing  as  well  as  command  and  control  functions,  which  dictates  further 
experimentation  with  the  "test  bed"  to  ensure  it  meets  Army  require¬ 
ments.  Since  the  Air  Force  envisions  its  Automated  Tactical  Fusion 
Division  (ATFD)  as  only  a  collateral  processing  operation,  it  can  more 
readily  "use  the  test  bed  design  and  software"  as  developed.  Addi¬ 
tionally,  a  review  of  the  text  in  pages  11  through  13  portrays  a  logi¬ 
cal  strategy  which  does  not  equate  to  "uncertainty." 

8.  Page  7,  lines  13-16 

a.  Draft  -  The  Navy  and  Marine  Corps  are  monitoring  BETA  project  results 
and  are  considering  participation  in  joint  exercises,  both  these 
services  foresee  very  limited  application  to  their  own  projects. 

b.  Comment:  Modify  paragraph  for  accuracy. 

c.  Recommendation:  That  the  sentence  be  changed  to  read:  "The  Navy  and 
Marine  Corps  are  monitoring  BETA  project  results  and  are  considering 
participation  in  joint  exercises,  both  these  services  foresee  very 
limited  application  to  their  own  projects  at  this  time." 

9.  Page  12,  first  paragraph 

a.  Draft  -  A  plan  was  formulated  to  concurrently  test  BETA  with  an  automa¬ 
ted  files  management  system,  called  the  Technical  Control  and  Analysis 
Center  ....According  to  Army  officials,  this  plan  could  not  be  imple¬ 
mented  because  Technical  Control  and  Analysis  Center  development  fell 
one  year  behind  schedule, 

b.  Comment:  TCAC  is  not  simply  an  "automated  files  management  system." 

The  TCAC  provides  for  automatic  record  traffic  message  lnputlng,  automa¬ 
tic  extraction  of  data  from  selected  record  traffic  and  manually  inputed 
messages,  correlation  of  parametric  data,  automated  analysis  routines 
and  automated  support  to  mission  management.  The  Advanced  Development 
Model  (Signal  Electronics  Warfare  System)  ADM  (SEWS)  and  TCAC-D  Divi¬ 
sion  are  identical  In  both  hardware  and  software. 

TCAC  is  approximately  18  months  behind  schedule  due  to  delay  in  repro¬ 
gramming  of  funds  to  accomplish  the  program.  Funds  were  not  approved 
for  the  program  until  November,  1979.  Delivery  of  TCAD-D  is  now 
expected  on  or  about  2D  Qtr  FY  82. 
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10.  Page  13,  line  21 

a.  Draft  -  Therefore,  the  Navy  believes  that  large  scale  application  of 
BETA  to  support  the  Navy's  requirement  is  not  feasible  and  there  is 
no  plan  to  utilise  BETA-like  hardware  or  software  in  Navy  correlation 
systems. 

b.  Comment:  Present  BETA  hardware  and  software  is  in  fact  similar  to  the 
Navy's  currently  operational  correlation  system  tailored  to  maritime 
target  data  processing.  Present  BETA  technology  does  not  significantly 
Improve  upon  current  Navy  operational  capabilities. 

c.  Recommendation:  Change  to  read:  "Therefore,  the  Navy  believes  that 
large  scale  application  of  BETA  to  support  the  Navy's  requirement  is 
not  feasible  and  there  is  no  plan  to  utilize  present  BETA  developed 
hardware  or  software  in  Navy  correlation  systems.” 

11.  Page  14,  line  6 

a.  Draft  -  By  providing  a  ground  situation  display,  the  center  would  support 
the  command  and  control  of  the  amphibious  operation. 

b.  Comment :  Clarification  to  recognize  possible  use  of  graphic  display 
terminals  already  in  Navy  inventory. 

c.  Reconmendatlon:  Change  to  read:  "By  providing  ground  situation  infor¬ 
mation,  the  center  would  support  the  coonand  and  control  of  the  amphibious 
operation. " 

12.  Page  14,  line  9 

a.  Draft  -  A  land-based  correlation  center  could  help  direct  Naval  gunfire 
support  through  ground  displays  through  its  target  nomination  capability. 

b.  Comment :  Clarification  to  recognize  possible  use  of  graphic  display 
terminals  already  in  Navy  inventory. 

c.  Recommendation:  Change  to  read:  "A  land-based  correlation  center  could 
held  direct  Naval  gunfire  support  by  providing  ground  situation  infor¬ 
mation  to  gunfire  support  ships." 

13.  Page  14,  lines  18-22 

a.  Draft  -  If  the  above  requirements  are  to  be  supported,  ground  target 
nominations  must  be  integrated  into  shipboard  command  and  control 
systems.  At  the  time  of  our  review,  the  Navy  had  not  developed  a 
technical  approach  to  accomplish  this  integration. 

b.  Comment:  Shipboard  systems,  not  necessarily  all  available  on  a  given 
ship.  Include  those  categorized  as  Command  and  Control,  Combat  Direction, 
and  Intelligence  Support.  It  is  consiuered  premature  to  assume  BETA's 
ground  target  nominations  should  be  integrated  into  shipboard  command 
and  control  systems. 
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13.  Page  14,  line  18  (continued) 

a.  Recommendation:  Change  to  read:  "If  the  above  requirements  are  to 
be  supported,  BETA-derlved  Information  must  be  provided  to  supporting 
Naval  Forces.  At  the  time  of  our  review,  the  Navy  had  not  developed 
a  technical  approach  to  accomplish  this." 

14.  Page  IS,  line  IS 

a.  Draft  -  The  similarity  of  intelligence  needs  in  land  warfare  raises 
a  question  whether  any  substantive  differences  exists  between  Army 
and  Marine  Corps  information  requirements,  and  the  need  for  the  Marine 
Corps  to  continue  development  of  systems  having  functions  similar  to 
those  included  in  BETA.  Therefore,  the  Marine  Corps  effort  may  nearly 
duplicate  the  BETA  effort  and  continued  development  of  their  IAC  could 
compound  the  existing  problem  of  software  and  equipment  compatibility 
and  interoperability  of  equipment  and  software  becomes  extremely  impor¬ 
tant  during  crisis  management  and  during  periods  of  armed  conflict. 

b.  Comments:  Differences  do  exist  between  Army  and  Marine  Corps  informa¬ 
tion  requirements  and  the  method  of  handling  that  information.  The 
Marine  Corps  doctrinally  operates  in  a  different  environment  -  amphi¬ 
bious  warfare  with  primary  support  from  the  Navy  -  and  will  (probably) 
work  the  problem  at  a  different  level  (the  Army  is  concerned  with  Corps- 
level  and  higher  including  theater-level).  A  direct  comparison  of  Army 
and  Marine  Corps  requirements,  with  the  assumption  that  these  require¬ 
ments  are  the  same,  is  incorrect. 

The  Intelligence  Analysis  Center  (IAC)  does  not  duplicate  ASAS  functions. 
If  anything,  it  should  be  compared  with  the  Air  Force  Display  Control/ 
Storage  Retrieval  (DC/SR).  The  IAC,  as  does  DC/SR,  contains  a  detailed 
comprehensive  intelligence  data  base.  The  IAC,  through  the  Naval  Intel¬ 
ligence  Processing  System  (NIPS)  digitized  data  base,  provides  the 
Landing  Force  Commander  (MAGTF  Commander)  with  his  link  to  the  Navy' 3 
intelligence  system  as  well.  It  is  not  intended  to  handle  rough  combat 
information  such  as  raw  sensor  reports,  which  may  be  used  to  develop 
near  real  time  (NRT)  targets.  This  follows  the  Air  Force  plan  to  have  a 
Tactical  Fusion  Division  (follow  on  to  BETA)  complement  the  DC/SR:  the 
TFD  will  correlate  NRT  sensor  reports,  pass  target  nominations  to  the  G-3 
structure,  this  correlation  would  (probably)  be  performed  in  the  Tactical 
Combat  Operations  (TCO)  system,  then  passed  to  Marine  Integrated  Fire  and 
Air  Support  System  (MIFASS)  for  targeting,  and  the  IAC  for  data  base 
updates.  The  ASAS  Is  intended  to  include  the  correlation  capability, 
along  with  a  very  limited  resident  data  base  (at  the  division  and  corps 
levels),  to  support  NRT  targeting  and  tactical  (combat)  intelligence 
production  only.  The  detailed  intelligence  data  base,  as  duplicated  by 
NIPS,  is  found  at  levels  above  Corps. 
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14.  Page  IS  (continued) 

Interoperability.  The  IAC  can  accept  JINTACCS  formatted  reports 
through  the  AUTODIN  system.  OSD  has  directed  that  selected  service 
systems  be  fully  Interoperable  with  similar  other-service  systems. 

In  the  Marine  Corps  automated  C^I  program,  this  would  be  effected 
through  the  TOO  system,  our  executive  c2  system,  which  would  be 
expected  to  fully  Interoperate  with  equivalent  service  systems  in 
the  joint  environment. 

c.  Recommendation;  That  the  paragraph  concerning  Army  and  Marine  Corps 
information  requirements  snd  addressing  the  possible  redundancy  between 
the  IAC  and  a  BETA- like  system  be  deleted  in  its  entirety,  and  replaced 
with  the  following: 


"Although  many  of  the  Information  requirements  of  the  Army  and  the 
Marine  Corps  are  similar  on  the  surface,  major  differences  exist  in 
the  environment  In  which  the  Information  is  processed  and  the  manner 
In  which  it  is  handled  doctrinally.  The  Marine  Corps  is  preparing 
to  field  its  Intelligence  Analysis  Center  which  is  functionally 
similar  to  the  Air  Force  TIPI  DC/SR  and  provides  the  Marine  Air- 
Ground  Task  Force  commander  with  a  direct  link  to  the  Naval  Intelli¬ 
gence  Processing  System.  The  Marine  Tactical  Combat  Operations  System 
(TCO),  currently  under  development,  will  provide  combat  information 
and  limited  raw  sensor  data  (to  include  target  nominations  for 
MIFASS)  to  the  division  level  and  below.  A  test  bed  for  the  TCO 
system  is  currently  being  fielded  at  Camp  Pendleton,  California. 
Personnel  running  this  test  bed  have  requested  all  BETA  software  deli¬ 
verables  to  be  utilized  in  further  developmental  work  in  order  to  de¬ 
termine  the  degree  of  applicability  of  BETA-derived  technology  to 
Marine  Corps  ADP  systems.  The  TCO  system  eventually  fielded  in  the 
1990  time-frame  will  be  fully  interoperable  with  equivalent  service 
C2  systems,  enhancing  ease  of  joint  service  C*." 


15.  Page  27 

a.  Draft  -  Department  of  the  Navy  funding  line: 

Current  Phase  Post  1980  Total 

1.00  2.20  3.20 

b.  Comment :  Clarification  needed  to  include  Navy  funds  provided  in  FY  79 
as  well  as  FY  80. 

c.  RecoBmendatlon:  Change  to  read; 

Current  Phase  Post  1980  Total 


3.0 


2.20 


5.20 
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Nr.  Richard  W.  Gutaann 
Dirac  tor 

United  States  General  Accounting  Office 
Logistics  and  Communications  Division 
Washington,  D.C.  20546 

Dear  Nr.  Gutmann: 


We  appreciate  the  opportunity  to  review  and  content  on  your  draft 
report  on  the  BETA  project.  We  consider  the  reonrt  to  be  an  objective 
and  constructive  review  of  this  difficult  technological  undertaking. 


At  the  same  time,  we  at  TRW  are  proud  of  our  performance  on  BETA 
and  are  pleased  to  provide  the  attached  fact  sheet  which  outlines  the 
progress  we  have  made  since  your  review.  In  short,  the  BETA  test  bed 
Is  now  In  good  shape.  Full  software  documentation  will  be  comolete 
bv  i  March  1981.  Tne  svsiam  nas  been  stabilized  and  we  feei  it  Is  now 
ready  to  serve  as'a  vital  technical  cornerstone  to  the  continuing 
development  of  a  joint  fusion  capability. 


Sincerely, 


Attach. 


Cf'ivsi  t**ci  mt.'«  c*  rm*.  »•..*  •  cvf  smc*  «».‘\*»O0Pf4c-  c *.  » .‘**.4  *  .*  •  •  •  •  <:r 
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TRW  COMMENTS  ON  SPECIFIC  GAO  CONCERNS 


I NT RO DUCT I ON/ BACKGROUND 

The  BETA  test  bed  program,  a  concept  originally  developed  by  DARPA,  was 
initiated  in  March  of  1978  under  the  management  of  a  Joint  Program  Office.  Its 
principal  milestone  was  a  European  Demonstration  in  the  Fall  of  1960.  The  pro* 
gram  to  design  and  develop,  within  a  2-1/2  year  period,  a  multi -service,  high- 
technology  system  testing  the  feasibility  of  innovative  state-of-the-art  multi¬ 
sensor  fusion/correlation  concepts  was  extremely  aefcltlous,  but  achievable. 

Due  to  a  slow  program  start  up  and  the  January  1979  descoping  which  delayed  the 
completion  of  system  design  phase,  significant  schedule  compression  was  Induced 
Into  the  later  portions  of  the  program. 

Subsequent  to  the  successful  Multi  Center  Demonstration  in  December  1979, 
it  was  emphasized  to  TRW  by  OSDR&E  that  BETA  was,  in  effect,  a  Quick  Reaction 
Capability  (QRC)  program  which  had  to  achieve  the  European  milestone  in  September 
1980.  To  achieve  this  goal  a  major  restructuring  and  prioritization  of  project 
activities  was  necessary.  Major  Immediate  effects  of  this  redirection  included 
the  need  to  develop.  Integrate,  test,  and  train  In  parallel  rather  than  following 
slower-paced  and  less  risky  sequential  procedures.  It  also  became  necessary  to 
defer  all  tasks  which  were  not  essential  to  the  European  Demonstration.  Key 
among  those  deferred  tasks  was  software  documentation. 

Sensor  Data  Rate  Processino/Resoonse  Time 

Considerable  attention  has  been  focused  on  the  BETA  top  level  System  Specifi¬ 
cation  requirement  to  process  4000  reports/hour.  This  rate  is  predicated  upon  a 
hypothetical  sensor  suite  collecting  against  a  postulated  1990  Central  European 
Front  threat.  Although  it  is  a  BETA  requirement  constraint,  its  validity  Is  cer¬ 
tainly  questionable  particularly  with  a  tight  cost  and  schedule  restrictions. 

In  the  European  Certain  Rampart  FTX,  a  maximum  data  rate  of  from  200-500 
reports/hour  was  predicted.  To  ensure  success  at  this  rate,  BETA  was  required 
to  demonstrate  a  processing  capability  of  1000  reports/hour  during  the  CONUS 


36 


APPENDIX  II 


APPENDIX  II 


CPX.  Thl*  rate  was  demonstrated  consistently  ovar  tha  two- day  CRB.  Currently, 
•ETA  can  procasi  a  sustalnad  rata  of  2400  reports/hour  with  paak  rataa  of 
4000  raports/hour  ovar  axtandad  time  periods.  At  these  rates  tha  correlation 
tlaellness  Is  lass  than  two  seconds  par  report  against  a  specified  requirement 
of  five  seconds. 

Oft  Status 

At  tha  time  of  Correlation  Center  Integration  Tests  the  Discrepancy  Report 
(DR)  status  was  as  Indicated,  however,  some  amplification  Is  warranted.  The 
number  of  DR's  Is  certainly  reasonable  and  consistent  with  other  software 
development  efforts  of  this  size  and  complexity.  Many  DR's  were  duplicate 
statements  of  the  same  problem,  l.e. ,  analysis  and  problem  fixing  simultaneously 
closes  several  DR's.  In  addition,  the  so-called  deferred  Dft'-s  represents  a 
desired  capability  and  "wouldn't  It  be  nice  If"  Instead  of  a  legitimate  specified 
system  problem. 

Examples  cited  as  Communications  Software  discrepancies  were.  In  fact,  not 
always  caused  by  software  DR's,  but  by  other  factors  such  as: 

1.  Fibre  optics  hardware  design  problems  which  have  been 
subsequently  Isolated  and  fixed,  and 

2.  Operator  error  In  affixing  message  routing  Indicators. 

It  Is  Important  to  note  that  currently  all  DR's  which  were  considered 
significant  by  the  project  office  have  been  corrected. 

Software  Configuration  Control 

The  GAO  report  indicates  that  Software  Configuration  Control  was  lost 
during  the  test  and  Integration  timeframe.  This  statement  requires  some  dis¬ 
cussion.  The  software  developed,  tested  and  Integrated  into  the  BETA  system 
consists  of  several  major  packages,  namely: 

1.  Coomunicatlon  software 

2.  Operator  Terminal  software 

3.  Data  Base  Management  software 

4.  System  Support  software 

5.  RSX-11M  Operating  System  software  and 

6.  Applications  software 
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Standard  configuration  control  procedures  war*  Maintained  on.all  Major 
packages  with  the  exception  of  the  Applications  software  which  coMprlsed 
approximately  one- sixth  of  the  total  software  developed.  The  fast  Moving  QftC 
pace  of  the  Integration  phase  during  the  last  two  Months  prior  to  the  CPX  over¬ 
stressed  the  configuration  management  procedures  that  had  been  developed  for  the 
Application  software.  This  resulted  In  a  definite  tlMe  lag  between  the  Integrated/ 
tested  software  and  the  appropriate  official  software  documentation. 

Subsequent  to  the  CONUS  CPX.  this  probleM  was  corrected  by  baselining  the 
Applications  software  and  establishing  a  more  responsive  configuration  control 
system. 

Operator  Terminal  Availability 

The  single-most  significant  problem  which  prevented  BETA  from  supporting 
the  European  exercise  was  specifically  the  Operator  Terminal  availability  which 
at  times  has  been  Improperly  and  erroneously  described  and  Measured. 

The  Operator  Terminal  (OT)  is  an  advanced,  state-of-the-art,  microprocessor 
based  computing  system.  These  terminals  were  developed  specifically  In  response 
to  BETA'S  unique  requirements  for  distributed  processing.  Numerous  hardware 
design  problems  were  discovered  on  the  terminals  as  the  terminal  hardware  and 
software  were  Integrated.  The  principal  Manifestation  of  the  hardware  design 
deficiency  was  keyboard  lockout,  l.e.,  the  OT  would  no  longer  respond  to  any 
operator  actions  causing  the  terminal  to  be  totally  Inoperable  until  the  entire 
terminal  Initialization  process  had  been  completed  -  this  requiring  about 
15  minutes.  It  should  be  pointed  out  that  despite  numerous  terminal  lockout 
occurrences  during  the  CPX  demonstration;  the  correlated  data  base  was  never 
Inaccurate  nor  destroyed.  The  significance  of  this  Is  that  upon  reinitialization 
a  terminal  was  again  fully  operational. 

As  a  result  of  a  determined  and  sustained  effort  by  a  confined  TRW/Aydln 
Tiger  Team  numerous  design  changes  have  been  identified  and  successfully  tested 
yielding  an  extremely  stable  configuration.  In  addition  and  to  provide  further 
Insurance,  a  fault  tolerant  warm  start  software  fix  has  been  Identified  and  Is 
being  developed. 
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UMW  .1 

The  concerns  11  luari  noted  by  the  MO  report  wtrt  valid  and  vara  abarad 
TXM  nonage rs.  Corrective  action  has  boon  taken  ta  the  significant  banaflt 
the  SETA  ;ost  ltd  Prograa. 
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BETA  CENTRAL  PROCESSING  EQUIPMENT 

PHOTO  COURTESY  OF  THE  BE  ( A  JOINT  PROJECT  OFFICE 
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BETA  OPERATOR  TERMINAL 

PHOTO  COURTESY  OF  THE  BETA  JOINT  PROJECT  OFFICE 


BETA  SITUATION  DISPLAY 

PHOTO  COURTESY  OF  THE  BETA  JOINT  PROJECT  OFFICE 
LEGEND  UNKNOWN  RADAR 

'Y'  SINGLE  CHANNEL  RADIO 


SOLID  AND  DASHED  LINES  REPRESENT  ROADS.  URBAN 
IZED  AREAS  AND  MANEUVER  CONTROL  MEASURES 
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DELETIONS  IN  BETA  SYSTEM 


FUNCTIONAL  REQUIREMENTS  (note  a) 
(Bare  Bones  BETA  Configuration) 


Deleted 

function 

Automated  BETA  interface 
module  filtering 


Division  correlation 
center 


Sensor  bias  correction 


Accounting  for  sensor 
cueing  request 


Automated  correlation  of 
mover  reports 


Impact 


Reduced  system  capability 
to  handle  high  message 
volume  (for  sensor  ground 
stations  without  filtering 
capability ) . 

System  no  longer  able  to 
validate  division  level 
fusion  requirements  and 
corps/division  level 
interoperability  processes/ 
activities . 

System  no  longer  able  to 
correct  for  location  error 
in  sensor  input  data. 
Location  error  correction 
cannot  be  manually  performed 
by  terminal  operator. 

System  no  longer  able  to 
monitor  status  of  operator 
requests  to  direct  sensors 
to  specific  geographic  areas 
Operator  must  perform  this 
task  manually. 

System  no  longer  able  to 
correlate  reports  of  moving 
targets,  e.y.,  a  tank  column 
Function  can  be  done  by 
using  query  function  and 
additional  manual  terminal 
operator  functions. 


a/Per  system  specification  change  in  January  1979. 
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Deleted 

function 

Sensor  coordinated  unique 
tools 


Hold  capability 


Terminal  response  time 
criteria 


Automatic  data  base 
update 


Impact 

System  no  longer  able  to 
aid  sensor  coordinator  per¬ 
form  such  tasks  as  mission 
planning  and  sensor  cover¬ 
age  areas  and  times.  Task 
must  be  done  manually. 

System  no  longer  able  to 
automatically  prevent  or 
inhibit  purge  of  target 
sightings  placed  in  status. 

System  response  time 
specification  changed  from 
not  to  exceed  to  an  average 
time  for  all  responses. 
Could  result  in  slower  sys¬ 
tem  response  time. 

System  no  longer  able  to 
automatically  notify  opera¬ 
tor  of  possible  target 
aggregation.  Additional 
manual  steps  required. 
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SECOND  PHASE  OF 

DELETIONS  IN  BETA  SYSTEM  FUNCTIONAL  REQUIREMENTS  (note  a) 
(Bare  Bones  BETA  Minus  Configuration) 


Deleted 

function 


Correlation  ambiguity 


Component  collection 


Automatic  shared 
situation  displays 


Automatic  data  base 
saturation  maintenance 


Dynamic  filter  mainte¬ 
nance  for  sensor  re¬ 
ports 


Impact 

System  no  longer  able  to  dif¬ 
ferentiate  between  possible 
correlation  and  noncorrelation 
of  target.  This  differentia¬ 
tion  must  be  done  manually  by 
operator. 

System  no  longer  able  to  look 
at  lower  level  entities  in 
order  to  link  with  a  higher 
entity.  Replaced  by  additional 
manual  linking  operations  and 
increased  use  of  cross¬ 
correlation. 

System  no  longer  able  to 
automatically  send  snapshot 
of  current  situation  to  other 
correlation  centers.  Requires 
additional  manual  operations 
by  terminal  operator. 

System  no  longer  able  to 
automatically  purge  data  base. 
Operator-inhibit  purge  no 
longer  needed.  Manual  purge 
must  be  used. 

System  no  longer  able  to  change 
filter  requirements  in  response 
to  changes  in  the  target  situa¬ 
tion.  Filtering  will  be  done 
by  static  requirements  which 
can  be  changed  at  each  system 
startup. 


a/These  deletions  were  directed  by  the  BETA  project  office  in 
August  1979. 
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Deleted 

function 


Saved  displays 


Boolean  template 
processing 


Impact 

System  no  longer  able  to 
differentiate  between  messages 
and  displays  stored  in  terminal 
operator  working  file  from 
routine  messages  and  displays 
sent  to  operator  for  action. 
Additional  manual  sort  operations 
required  by  terminal  operator. 

System  no  longer  has  factory 
preset  unit  identification 
parameters.  Parameters  must  now 
be  put  into  system  by  terminal 
operator  as  an  additional  manual 
step. 


(941192) 
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